This is a really nice improvement catching config issues early with clear error messages will make things much easier to debug, especially for new users. I also like that validation happens right after loading the config and that you added targeted tests for the new cases. I had a few thoughts mainly around how this might scale as more config options get added:

1. Right now all the checks seem to live inside validate_config. That works well for now, but I wonder if it might get a bit crowded over time. Maybe grouping validations by sections (like datastore, training, etc.) could help keep things organized as it grows.

2. It might also be worth standardizing the error messages a bit more for example, always including the full config path (training.state_feature_weighting) and keeping a consistent format for suggested fixes.

3. Since this is meant to support future additions (like probabilistic forecasting configs), it could be useful to have a clear pattern for adding new validation rules, so contributors don’t have to modify one large function every time.

Out of curiosity, do you plan to expand validation to more fields over time, or keep it focused on the most common failure cases? Overall though, this is a great step toward making config errors much more user-friendly.

Thanks @princekumarlahon, really appreciate the detailed feedback!

These are all good points. To respond to each:

1. Grouping by section — agreed that a flat validate_config will get crowded as more fields are added. One approach would be breaking it into _validate_datastore and _validate_training helpers called from the main function, so each section stays self-contained. Happy to restructure it that way in a follow-up commit if that direction makes sense to the maintainers.

2. Consistent error message format — makes sense. Right now the path format is consistent (datastore.config_path, training.state_feature_weighting) but the suggested fix wording varies slightly between checks. I can tighten that into a fixed template — something like [field]: <what's wrong>. Example fix: <yaml snippet> — so all messages follow the same structure.

3. Extensibility pattern — the intent was exactly this: new fields get registered in one place with their error description, rather than buried in ad-hoc conditionals. If the current structure isn't clear enough on that, I can add a short comment above the validation calls explaining the pattern.

On your question about scope: the plan is to keep the initial PR focused on the two most failure-prone cases (missing datastore file, empty manual weights) and expand incrementally as new config fields are introduced — especially the ones needed for the probabilistic forecasting extension. That way each addition stays reviewable and testable on its own.

Let me know if you'd like me to address any of these before review, or if it's better to handle them as follow-up PRs.

This sounds great I like the direction. Splitting validation into section-based helpers and standardizing error messages both make sense. And +1 to keeping this PR focused and handling structural improvements as follow up. I think this is in a good place